Transport networks are considered scarce shared resources and bandwidth demand is difficult to predict and manage. With the deployment of Wireless Fidelity (Wi-Fi), third generation (3G) and fourth generation (4G) radio access networks, the mobile transport network, i.e., the backhaul packet network, is becoming the bandwidth bottleneck (BB), which is defined as the lowest bandwidth along the complete path between the mobile subscriber and the service endpoint, e.g., the Internet. With long term evolution (LTE) networks, the requested Guaranteed Bit Rate (GBR) for a subscriber GBR connection or the requested Aggregate Maximum Bit Rate (AMBR) for the subscriber Non-GBR connections will soon surpass 300 Mbps, thus making it possible for a single subscriber to consume a large portion or all of the transport network resources available between a radio access node and a mobile core network.
Furthermore, coordination capabilities between distributed radio access nodes are needed to improve the user packet delivery due to interference caused by the densification of the radio network (larger number of small and larger radio access nodes in a given geographical area). Such radio coordination capabilities do not perform well (or not at all) if the transport delay between radio access nodes is large relative to a threshold value or if the available capacity between the radio access nodes is small relative to a threshold value.
Current radio access technologies, such as Wi-Fi, 3G or 4G, do not dynamically account for the variable quality (packet delay and loss) and available capacity of the mobile transport network when admitting a new subscriber on a radio access node, delivering or scheduling user packets to mobile subscriber devices, or when managing radio coordination between access nodes.
The deployment of a bandwidth broker server within each radio access network has been proposed to improve admission control. The bandwidth broker does not address radio link scheduling and radio service activation. It is also a single point-of-failure and requires additional signaling processing in the radio access network and adds significant delay during admission control and handover decisions.
The radio resources are managed by technologies, protocols, tools or methods often referred as radio admission control (RAC), responsible for mobile subscriber connection handling and radio resource management (RRM), where RRM is responsible for radio bearer traffic scheduling and link adaptation. In LTE networks, the radio resources are managed by distributed radio access nodes like the eNodeBs (eNB) and Home eNodeBs.
The transport network (TN) resources are managed by different technologies, e.g., Internet Protocol (IP), Ethernet, multi-protocol label switching (MPLS), protocols, tools or methods often referred to as data traffic engineering. The main objective of traffic engineering is to achieve the lowest transport cost by finding the best possible placement of the offered data traffic over the transport network topology. The TN resources are managed by TN nodes such as routers and switches, and can be remotely monitored by radio access nodes, such as the eNodeBs.
The radio access nodes, such as the eNodeBs and Home eNodeBs, that are responsible for subscriber connection admission control and radio resource coordination and management are not aware of the actual transport network quality and capacity to each peer (neighbor radio access node or mobile core node (MCN)). The third generation partnership project (3GPP) and Internet engineering task force (IETF) standard specifications do not indicate what resource information should be exchanged between the transport and radio networks and how this information should be exchanged. Radio resources and transport resources are currently optimized and managed separately.
One existing solution is to configure the radio admission control on each radio access node with a set of static parameters best representing the available transport resources. For instance, maximum downlink (DL) bandwidth, maximum downlink delay, maximum uplink (UL) bandwidth and maximum uplink delay parameters can be estimated and configured across a given transport interface capable to reach the appropriate core nodes and neighbor access nodes. When a new GBR bearer is requested or is handed over to a new access node, the requested uplink and downlink guaranteed bit rates in bits per second can be compared against the remaining bandwidth in each pool to determine if the bearer should be accepted or rejected. This method has serious limitations. It is difficult to configure and optimize and, does not generate satisfactory results since the resource parameters are static and do not necessarily reflect the actual available bandwidth capacity or actual delay/loss characteristics at a given instant in time.
Another existing solution is to react and manage the congestion across the mobile transport network by configuring differentiated services code point (DSCP)/p-bit marking, classification and class-based traffic management. This solution is designed to protect the high priority traffic against link congestion caused by low priority traffic. This method has serious limitations, as the method does not prevent congestion that can occur for the high priority traffic and queue management techniques, including random early detection (RED). The method also does not provide equal or specific drop probability for subscribers sharing the same low priority class, since the transport nodes cannot distinguish the individual general packet radio service (GPRS) tunneling protocol-user (GTP-U) tunnels or subscriber connections.
Another existing solution is to react and manage the congestion across the mobile transport network by carrying congestion signals or explicit congestion notification (ECN) markings back to the transport sender where the sender is expected to reduce its rate in response. Such mechanisms and protocols are discussed in the Internet engineering task force (IETF) congestion exposure (CONEX) working group. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for handling transport congestion and how this congestion indication can be delivered to the sender of the traffic. One serious limitation of the CONEX protocol is that all devices and nodes, including the user equipment, may need to be CONEX-enabled to work effectively. Another limitation is that the CONEX protocol does not actually measure the transport network quality or capacity, but instead, reacts to link congestion along the path.
Another existing solution is to introduce a bandwidth broker server within each radio access network, where the broker is responsible for collecting and correlating the load status on all paths in the radio access network and to accept/deny each subscriber connection request when a path across the transport network is congested. This method also has serious limitations. It requires deployment and management of additional servers in each radio access network; potentially one set of servers per radio access technology, e.g., evolved universal terrestrial radio access network (E-UTRAN), UTRAN and global system for mobile communication (GSM). The method requires continuous transfer of all path performance information to a centralized server consuming unnecessary transport network resources. The server may not always have the real-time state of the network, causing inaccurate decisions. Fundamental changes to the signaling architecture is required when a bandwidth broker is introduced, requiring a new bandwidth broker client or radio network server. This would add significant delay of up to 50 ms during admission control and handover decisions, while it is desirable to make such decision in 1 ms or less for X2-based handovers between eNodeBs. The method to measure the load on each hop is not easily deployable if each node along the path is involved in the measurement process by: updating the probe packet, and creating protocol dependencies between the transport network nodes and the endpoint nodes responsible to inject or reflect the test traffic.